AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される
AWS ドキュメントに IAM コントロールプレーンとデータプレーンの記述が増えた
コンバンハ、千葉（幸）です。
ひとまず以下の絵を 90 秒くらい眺めてください。
眺めましたか？
まだ 30 秒も経ってなくないですか？せっかくなのでもうちょっと見てください。
……眺めましたね？
以上でこのエントリの内容は概ね終わりです。読んでいただきありがとうございました。
ちょっとだけ残りが続きます。
IAM レジリエンスのドキュメントに記述が増えてた
AWS IAM のレジリエンス（復元力、耐障害性）に関する記述は以下ドキュメントにあります。
上記のページは 2022/5/16 に更新されており、その段階で追記された内容は以下エントリにまとめました。
しばらくして再度のぞくとどうも見慣れない記述が増えている……と思い履歴を調べてみると GitHub 上では 2022/6/21 に更新が行われていました。（ AWS ドキュメント上ではもっと前から参照できました。）
この更新によって AWS IAM のコントロールプレーンとデータプレーンのある程度 具体的な記述が増えました。
AWS re:Invent 2021 の Keynote でそれらの言及があってから興味津々だったわたしとしては、とても嬉しい更新です。その内容をまとめたのが冒頭の一枚絵です。
更新内容を元に、もうちょっとだけ補足します。
AWS IAM コントロールプレーンはバージニア北部リージョンにある
IAM ロールやポリシー、ユーザーといった IAM リソースは IAM のコントロールプレーンに保管されています。これらに対する操作、例えば ポリシーの変更、ロールの追加などはコントロールプレーンに送信されます。
AWS IAM は特定のリージョンに依存しないグローバルサービスですが、そのコントロールプレーンはバージニア北部にのみ存在します。 *1
AWS IAM データプレーンは各リージョンで認証・認可を担う
コントロールプレーンに保存された IAM リソースはデータプレーンに配布されます。データプレーンは各リージョンに存在し、リージョンごとに少なくとも 3 つのアベイラビリティゾーンに分散されています。
IAM リソースの操作（ポリシーの変更など）により行われたコントロールプレーンの設定変更は、 IAM システムにより各リージョンのデータプレーンに伝播されます。データプレーンは IAM コントロールプレーン構成データのリードレプリカのようなものである、と表現されています。
各リージョンの IAM データプレーンが当該リージョンでの認証・認可を担います。AWS リソースの操作リクエスト（例えば EC2 インスタンスの起動など）はリージョンのサービスエンドポイントに送信され、その後 IAM データプレーンにパスされます。
AWS IAM は結果整合性
コントロールプレーンとデータプレーンが独立したインスタンスとして存在していることを把握したところで改めて思い出しておきたいのが結果整合性です。
世界中のデータセンター内のコンピューターを介してアクセスされるサービスとして、IAM は、結果整合性と呼ばれる分散コンピューティングモデルを採用しています。IAM (または他の AWS サービス) で行った変更は、属性ベースのアクセスコントロール (ABAC) で使用されているタグを含め、すべての可能なエンドポイントから認識されるまでに時間がかかります。この遅延は、サーバー間、レプリケーションゾーン間、世界中のリージョン間でのデータ送信にかかる時間から発生している場合もあります。IAM ではパフォーマンス向上のためにキャッシュも使用しているため、これが原因で遅延が発生することがあります。変更は、以前にキャッシュされたデータがタイムアウトになるまで反映されない場合があります。
この記述は以前からドキュメントに存在しましたが、改めて読むとより理解が捗る気がします。
リージョンの有効化時に行われる IAM リソースの配布
香港リージョンやミラノリージョンなど、デフォルト無効のリージョンを利用したい場合には明示的に有効化する必要があります。リージョンを有効化したタイミングで IAM リソースの配布が行われるということで、想像すると楽しいです。
リージョンを有効にすると、そのリージョンへの IAM リソースの配信など、AWS がそのリージョンでアカウントを準備するためのアクションを実行します。ほとんどのアカウントでは、このプロセスに数分かかりますが、数時間かかることがあります。このプロセスが完了するまでそのリージョンを使用することはできません。
IAM レジリエンスのまとめ
以前に確認した内容も含め、上記ページに記載されている内容を改めてまとめます。
- AWS IAM と AWS STS はグローバルに利用できる自立したリージョンベースのサービスである
- IAM は予期しない障害が発生した場合でもサービスが認可されるようにコントロールプレーンとデータプレーンが分かれている
- IAM リソースはコントロールプレーンに保存されている
- IAM リソースの変更リクエストはコントロールプレーンに送信される
- 商用リージョン向けのコントロールプレーンはバージニア北部リージョンに存在する
- コントロールプレーンでの設定変更は有効な AWS リージョンのデータプレーンに伝播される
- 各 AWS リージョンに IAM データプレーンの独立したインスタンスがあり、同じリージョンでのリクエストの認証・認可を行う
- 各リージョンで IAM データプレーンは少なくとも 3 つのアベイラビリティゾーンに分散されている
- IAM コントロールプレーンとデータプレーンはどちらも計画的ダウンタイムがゼロになるよう構成されている
- AWS STS リクエストはデフォルトで単一のグローバルエンドポイントに送信される
- リージョナル STS エンドポイントを使用することでレイテンシーの軽減やアプリケーションに追加の冗長性を提供できる
- 特定のイベントによりネットワークを介した AWS リージョン間の通信が中断されることがある
- （クライアントが）グローバル IAM エンドポイントと通信ができない場合でも以下は可能である
- AWS STS による IAM プリンシパルの認証
- IAM によるリクエストの認可
- 通信を阻害するイベントにより AWS サービスへのアクセス能力は変わるが、多くの場合 IAM クレデンシャルの利用を継続できる
- リージョン内での永続的なアクセスキーを用いた認証は継続できる
- STS リージョナルエンドポイントを利用して少なくとも 24 時間は新しい一時的な認証情報をリクエストできる
- IAM リソースの追加・変更は失敗する可能性がある
- IAM リソースの変更の反映に時間がかかる場合がある
- マネジメントコンソールへのサインインが影響を受ける場合がある
- AWS リージョンおよびアベイラビリティゾーンのレジリエンスを活かすために以下のベストプラクティスに則る
- AWS STS のグローバルエンドポイント代わりにリージョナルエンドポイントを使用する
- IAM リソースの設定変更の即時反映が要求される構成は見直す
裏側に思いを馳せると楽しい
AWS IAM のコントロールプレーンとデータプレーンに思いを馳せました。
ただ利用するだけであれば知らなくてもいいことですが、裏側の仕組みを想像しながら使うとより楽しく AWS を使えると思います。
今度 IAM ユーザーを作成するときにでも、各リージョンにじわ〜と拡がっていくさまを想像してみてください。
以上、 チバユキ (@batchicchi) がお送りしました。
脚注
- AWS IAM のグローバルエンドポイント`iam.amazonaws.com`を名前解決して得られるグローバル IP アドレスのロケーションを調べるとバージニアになっていることからもそれが窺えます。 ↩
